Resource-based APIとUsecase-based APIの勘所
それぞれ一長一短だが、この2種類のAPIをシステム自体のライフサイクルの違いに合わせて分割すると、柔軟な開発サイクルを支えてくれる リソース自体に変化があるわけじゃないなら、その部分は残したい その境界で、バックエンドのサーバーor Web APIごと分けてしまうというモチベーションが生まれる 前者を選択するとクライアントの実装難易度や複雑性が高まっていく
すごく単純化すると「ID=2のUserのデータがほしい」ではなく「ID=2のユーザーの名前を表示するためのデータがほしい」 そのユースケースにとってはユーザーの名前がUserテーブルのNameカラムに保存されているとかそんなことはどうでもよい ただユーザーの名前がほしい、というニーズだけがある
ここはGraphQLのようにフロントエンドでほしいデータの形を定義するのがマッチする https://scrapbox.io/files/63368ba09d2e3f001dd7ef8b.png
クライアントはまっさきに壊されるが、それは宿命として諦める
どっちがいいの
GraphQLはスキーマの運用コストや開発コストが高くてメンバー次第では採用するのが難しいかも リソースを考察するというスキルが不十分である
リソースを考察することに時間をかけるメリットが少ない
内部品質よりも初期のスピードが重要である
経験豊富な開発者がいない
作っているものがユースケースに強く依存しているにも関わらずそれをリソースとして捉えようとしてうまくいかない RESTAPIの場合は明らかにユースケースに依存しているとわかれば、割り切って特定の endpoint にユースケースの名前をつけてしまって (GET /usecase_name) それ専用のものにしてしまえばいい そうしてもおくことでユースケースに対するスケール性をある程度担保できる
まとめ
≒ データベースのテーブル設計を良くすること
これをサボると Usecase-based なテーブル設計になるが、より短期間でシワ寄せがくることが容易に想像がつくだろう
ここは経験すればするほど上手くなる(良いものを速く作れるようになる)し、自らの成長のためにもサボるべき箇所では決してない
DDDするというわけではなく、ドメインの設計をデータベースのモデルに落とし込む表現力が大事 バックエンド/フロントエンド問わず、どのイベントの発生によりどのリソースが芋づる式に影響するのかは理解しておいたほうが良い
フロントエンド寄りのkoushisa.icon視点では
要件次第でモバイル専用のWeb API生やすとかなると流石に限界はあるかもしれない APIの背後にあるスキーマを運用する知識やそのコミュニケーションの効率化に労力を割くほうが全体最適化に繋がる
2023/12/25 一年ぶりに追記
参考